Tunneling SSH

Comme son nom l'indique, le Tunneling SSH va consister en l'établissement d'un tunnel construit avec le protocole SSH entre un client et un serveur. Jusque-là, rien de très complexe, c'est comme cela que nous travaillons depuis le début du cours. Nous avons également vu que, via SSH, il est possible de faire transiter d'autres protocoles, tels que le FTP (qui devient alors SFTP). C'est un peu ce principe que nous allons reprendre.

Pour avoir une meilleure vision de ce que l'on peut faire avec un Tunnel SSH, prenons un cas concret :

Je dispose d'un serveur Linux sur lequel tourne un serveur web, en écoute sur le port 80, et un service SSH, en écoute sur le port 22. Étant à distance, je suis obligé de passer par internet pour accéder à mon serveur web. Les informations que je dois passer à mon serveur web sont sensibles et je n'ai aucune envie qu'elles transitent en clair sur un réseau auquel je ne fais pas confiance. Une solution qui s'offre à moi : le tunneling SSH.

Je vais établir une connexion SSH sur mon serveur distant puis, en local depuis cette connexion SSH, contacter mon service HTTP. Le flux HTTP passera donc à l'intérieur du flux SSH, il sera alors chiffré à l'intérieur de mon tunnel SSH.

ssh-linux-23ssh-linux-23

Pour être techniquement plus précis, nous allons faire correspondre un port local de notre machine à un port distant de la machine sur laquelle on se connecte, le tout au travers de notre connexion SSH :

ssh -f user@monserveur -L 2500:localhost:80 -N

Dans ce schéma, j’établis donc une connexion SSH entre mon client et mon serveur. Je précise ensuite via l'option "-L" que le port 2500 de mon poste local va correspondre au port 80 de ma machine distante. Autrement dit, toutes données envoyées des informations sur le port local 2500 atterriront sur le port 80 de ma machine distante, mais passeront au travers mon tunnel SSH, ce qui correspond au schéma vu précédemment.

Voici le détail des options utilisées :

Nous pouvons alors faire le test avec, soit un navigateur web, soit une commande "wget" qui va se charger d'aller chercher la page web de notre client. Avec wget :

wget http://127.0.0.1:2500/index.html

Nous obtiendrons alors l'index.html du serveur distant, cela signifie donc que la requête HTTP passée en localhost sur le port 2500 a été redirigée sur le port 80 de mon serveur web, au travers de notre Tunnel SSH.

Une possibilité encore plus étendu de l'utilisation du tunnel SSH est le fait d'accéder, au travers un serveur SSH, à une machine qui ne nous est pas directement accessible en tant que client. Pour mieux comprendre, prenons ce schéma :
tunneling-ssh-01tunneling-ssh-01

Dans ce contexte, je ne peux pas accéder, en tant que client, aux serveurs locaux de mon LAN. Néanmoins, j'ai un accès en SSH à un serveur qui est connecté au LAN et à Internet. En utilisant la technique du tunnelling SSH, je vais pouvoir me connecter à mes serveurs locaux. Je commence par établir mon tunnel SSH :

ssh -f mickael@1.2.3.4 -L 2500:192.168.1.10:80 -N

Ici, je créé un tunnel SSH avec l'utilisateur "mickael" vers mon serveur SSH ayant l'IP "1.2.3.4". Ensuite, je spécifie les paramètres de mon tunnel :

La machine sur laquelle je me connecte en SSH peut, elle, être en liaison avec mon serveur web local, ainsi, au travers de mon tunnel SSH, je peux y avoir accès. Pour cela, je dois spécifier à mon client web que, pour aller sur mon serveur web, je dois, non plus essayer d'aller sur le port 80, mais plutôt aller sur mon port local 2500. Les flux seront ainsi redirigés dans mon tunnel SSH. C'est ce que nous avons fait plus haut de façon plus basique en spécifiant le port "2500" à la commande wget sous Linux. Voici un schéma qui vous permettra de visualiser le tunnel SSH et le flux jusqu'à un serveur à l'intérieur du LAN :

tunneling-ssh-05tunneling-ssh-05

Il est également intéressant de savoir que plusieurs tunnels SSH peuvent être établis en même temps, à condition qu'il ne forward pas (ne fassent pas correspondrent) les mêmes ports. Par exemple, j'ai ici un tunnel actif sur mon port local 2500, je peux en établir un deuxième sur le port 2501, pour établir une connexion avec mon serveur STMP local :

ssh -f mickael@1.2.3.4 -L 2501:192.168.1.10:25 -N

Pour accéder au serveur SMTP de mon LAN depuis mon client SSH, je doit spécifier à mon client de messagerie qu'il doit communiquer sur mon port local 2501, flux qui passera alors vers le tunnel SSH.

Établir un tunnel SSH depuis Putty

Nous avons ici vu comment établir un tunnel SSH depuis un client SSH Linux, en ligne de commande. Bien entendu, nous pouvons également faire cela avec les clients SSH PuTTY ou KiTTY.

On va commencer par initialiser une connexion SSH avec PuTTY ou KiTTY comme nous le faisons depuis le début du cours. Lorsque cette connexion sera initialisée, nous pourrons faire un clic droit sur le bord supérieur de la fenêtre pour atteindre l'option "Change Settings" :

tunneling-ssh-02tunneling-ssh-02Dans le panneau des paramètres nous pourront alors aller dans "SSH" puis "Tunnel". Ici, nous pourrons remplir les paramètres comme cela :
tunneling-ssh-03tunneling-ssh-03

Ici, dans la partie "source port", nous allons spécifier le port local qui sera mappé. Dans la partie "Destination", nous précisons la cible en sortie de tunnel. Cela peut donc, comme nous l'avons vu, être la machine locale (serveur SSH) ou distante avec un port spécifique. Il est à noter que nous pouvons ajouter comme cela plusieurs tunnels SSH. Il faudra valider notre paramétrage via le bouton "Add" puis nous validerons avec "Apply" en bas de fenêtre. Ensuite, nous pourrons effectuer un test en ouvrant un navigateur puis en visant l'URL "http://localhost:2503" :

tunneling-ssh-04tunneling-ssh-04

Nous voyons ici que la requête HTTP visant "localhost:2053" passe par notre tunnel SSH pour au final arriver en "127.0.0.1" sur le port "80" du serveur web LAN.

Nous avons fait le tour du tunneling SSH, c'est une notion quelque peu complexe car elle nécessite de bien visualiser les différents chemins des flux dans le tunnel SSH. Cependant, le tunneling SSH peut être très pratique et se révèle être un outil très efficace dans les situations opérationnelles.